4.1    Stakeholder Expectations Definition   4.2    Technical Requirements Definition  4.3    Logical Decomposition   4.4    Design Solution Definition   

Note: It is important to note that the team must not rely solely on the requirements received to design and build the system. Communication and iteration with the relevant stakeholders are essential to ensure a mutual understanding of each requirement. Otherwise, the designers run the risk of misunderstanding and implementing an unwanted solution to a different interpretation of the requirements. This iterative stakeholder communication is a critically important part of project validation. Always confirm that the right products and results are being developed.

The Technical Requirements Definition Process transforms the stakeholder expectations into a definition of the problem and then into a complete set of validated technical requirements expressed as “shall” statements that can be used for defining a design solution for the Product Breakdown Structure (PBS) and related enabling products. The process of requirements definition is a recursive and iterative one that develops the stakeholders’ requirements, product requirements, and lower level product/component requirements. The requirements should enable the description of all inputs, outputs, and required relationships between inputs and outputs, including constraints, and system interactions with operators, maintainers, and other systems. The requirements documents organize and communicate requirements to the customer and other stakeholders and the technical community.

Technical requirements definition activities apply to the definition of all technical requirements from the program, project, and system levels down to the lowest level product/component requirements document.

Figure 4.2-1 provides a typical flow diagram for the Technical Requirements Definition Process and identifies typical inputs, outputs, and activities to consider in addressing technical requirements definition.

Typical inputs needed for the requirements process include the following:

Other inputs that might be useful in determining the technical requirements:

The top-level requirements and expectations are initially assessed to understand the technical problem to be solved (scope of the problem) and establish the design boundary. This boundary is typically established by performing the following activities:

A complete set of project requirements includes those that are decomposed and allocated down to design elements through the PBS and those that cut across product boundaries. Requirements allocated to the PBS can be functional requirements (what functions need to be performed), performance requirements (how well these functions should be performed), and interface requirements (product to product interaction requirements). Crosscutting requirements include environmental, safety, human factors, and those that originate from the “-ilities” and from Design and Construction (D&C) standards. Figure 4.2-2 is a general overview on the flow of requirements, what they are called, and who is responsible (owns) for approving waivers.

With an overall understanding of the constraints, physical/functional interfaces, and functional/behavioral expectations, the requirements can be further defined by establishing performance and other technical criteria. The expected performance is expressed as a quantitative measure to indicate how well each product function needs to be accomplished.

Note: Requirements can be generated from non-obvious stakeholders and may not directly support the current mission and its objectives, but instead provide an opportunity to gain additional benefits or information that can support the Agency or the Nation. Early in the process, the systems engineer can help identify potential areas where the system can be used to collect unique information that is not directly related to the primary mission. Often outside groups are not aware of the system goals and capabilities until it is almost too late in the process.

Technical requirements come from a number of sources including functional, performance, interface, environmental, safety, human interfaces, standards and in support of the “’ilities” such as reliability, sustainability, producibility and others. Consideration and inclusion of all types of requirements is needed in order to form a complete and consistent set of technical requirements from which the system will be architected and designed. Figure 4.2-3 shows an example of parent and child requirement flowdown.

Initial Function Statement

The Thrust Vector Controller (TVC) shall provide vehicle control about the pitch and yaw axes.

This statement describes a high-level function that the TVC must perform. The technical team needs to transform this statement into a set of design-to functional and performance requirements.

Functional Requirements with Associated Performance Requirements

Finally, the requirements should be defined in acceptable “shall” statements, which are complete sentences with a single “shall” per statement. Rationale for the requirement should also be captured to ensure the reason and context of the requirement is understood. The Key Driving Requirements (KDRs) should be identified. These are requirements that can have a large impact on cost or schedule when implemented. A KDR can have any priority or criticality. Knowing the impact that a KDR has on the design allows better management of requirements.

See Appendix C for guidance and a checklist on how to write good requirements and Appendix E for validating requirements. A well-written requirements document provides several specific benefits to both the stakeholders and the technical team as shown in Table 4.2-1.

It is useful to capture information about each of the requirements, called metadata, for future reference and use. Many requirements management tools will request or have options for storing this type of information. Table 4.2-2 provides examples of the types of metadata that might be useful.

The rationale should be kept up to date and include the following information:

An important part of requirements definition is the validation of the requirements against the stakeholder expectations, the mission objectives and constraints, the concept of operations, and the mission success criteria. Validating requirements can be broken into six steps:

Requirements validation results are often a deciding factor in whether to proceed with the next process of Logical Decomposition or Design Solution Definition. The project team should be prepared to: (1) demonstrate that the project requirements are complete and understandable; (2) demonstrate that evaluation criteria are consistent with requirements and the operations and logistics concepts; (3) confirm that requirements and MOEs are consistent with stakeholder needs; (4) demonstrate that operations and architecture concepts support mission needs, goals, objectives, assumptions, guidelines, and constraints; and (5) demonstrate that the process for managing change in requirements is established, documented in the project information repository, and communicated to stakeholders.

Measures of Performance (MOPs) define the performance characteristics that the system should exhibit when fielded and operated in its intended environment. MOPs are derived from the MOEs but are stated in more technical terms from the supplier’s point of view. Typically, multiple MOPs, which are quantitative and measurable, are needed to satisfy a MOE, which can be qualitative. From a verification and acceptance point of view, MOPs reflect the system characteristics deemed necessary to achieve the MOEs.

Technical Performance Measures (TPMs) are physical or functional characteristics of the system associated with or established from the MOPs that are deemed critical or key to mission success. The TPMs are monitored during implementation by comparing the current actual achievement or best estimate of the parameters with the values that were anticipated for the current time and projected for future dates. They are used to confirm progress and identify deficiencies that might jeopardize meeting a critical system requirement or put the project at cost or schedule risk.

For additional information on MOPs and TPMs, their relationship to each other and MOEs, and examples of each, see Section 6.7.2.6.2 of the NASA Expanded Guidance for SE document at https://nen.nasa.gov/web/se/doc-repository.

Once the technical requirements are identified and validated to be good (clear, correct, complete, and achievable) requirements, and agreement has been gained by the customer and key stakeholders, they are baselined and placed under configuration control. Typically, a System Requirements Review (SRR) is held to allow comments on any needed changes and to gain agreement on the set of requirements so that it may be subsequently baselined. For additional information on the SRR, see Section 6.7.

The work products generated during the above activities should be captured along with key decisions that were made, any supporting decision rationale and assumptions, and lessons learned in performing these activities.

Refer to Section 4.2.2 of the NASA Expanded Guidance for SE document at https://nen.nasa.gov/web/se/doc-repository for additional information on: